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A METHOD OF PROCESSING DATA FOR A SYSTEM MODEL 

The present invention relates to tlie modeling of 
data using data processors such as computers. 

In its preferred form the present invention 
relates to spreadsheet modeling. For convenience the 
invention will be described with reference to spreadsheet 
modeling but should be understood as having wider 
applications such as other modeling applications. 

In the field of financial analysis computer 
models were originally developed to maJce it relatively 
quick and easy to examine many different scenarios and to 
calculate more complex indicators such as net present 
values. TO assist in this regard several computer 
modeling systems were developed in languages such as 
FORTRAN to facilitate the construction of computer models. 

Computer modeling systems had several attractive 
features including the ability to handle very complex 
calculations such as complex depreciation regimes and the 
maintenance of asset registers involving both depreciation 
and revaluation. Furthermore batch operation allowed 
0^^ex9Ll complex scenarios and sensitivities to be built 
and stored then rxin quickly when required. In addition 
computer modeling systems provided an ability to switch 
amongst alternatives or optional scenarios using available 
25 options. 

However coitas^uter modeling systems suffered from 
significant problems including the high level of 
programming expertise required, especially if the logic of 
the model needed to be changed. In addition they were 

30 invariably inflexible, because decisions needed to be made 
in advance regarding the order in which calculations were 
to be performed. Furthermore, because calculations were 
carried out in computer code hidden from view third party 
users often regarded the systems as black boxes and had 

35 little confidence in the output. 

AS an alternative to computer modeling systems 
spreadsheet systems were developed which had the advantage 
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of requiring little prograaiming expertise and provided 
more intuitive methods for inputting data, for specifying 
formulae and for displaying results. 

The spreadsheet system typically attenqpts to 
devise a schedule of calculations so that each cell value 
is calculated before the cell is itself required to be 
used in the calculation of cells which depend on it. 

If such a schedule can be created the spreadsheet 

system calculates the cells. 

Spreadsheet systems also have some drawbacks 
however. These include auditing problems associated with 
complex calculations where cell formula are cumbersome and 
difficult, m addition spreadsheet systems are typically 
poorly equiE«>ed for batch processing of complex and/or 
inter-related scenarios. Furthermore they have limited 
capability to switch amongst alternative or optional 
scenarios using options. Finally the lack of an interface 
for reading large amounts of input data can make data 
entry time c<»isuming and prone to error. 

Because of the above defects with spreadsheet 
modeling, modelers have tended to use two methods for 
creating coit«)lex spreadsheet models. These include 
comprehensive models inTrolving the creation of a 
comprehensive spreadsheet containing all reasonably 
conceivable calculations that might be encountered in the 
particular field. This has the disadvantage of large 
storage and execution time overheads and the provision of 
features which are rarely if ever used. 

Alternatively a standard model may be modified to 
handle calculations specific to the problem at hand. This 
naturally has the associated disadvantage of requiring 
considerable time and effort from the user in rewriting. 
This technique is also prone to errors. 

The present invention relates to a method of 
processing data ^ch can be incorporated into spreadsheet 
modeling systems. In its preferred form the method can be 
Incorporated in a hybrid spreadsheet modeling system 
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incorporating the best features of computer modeling 
systems and spreadsheet systems - 

According to one aspect of the present invention 
there is provided a method for processing data for a 
5 system model including tbe steps of providing a model 
specification having a plurality of types of items 
including at least one first item type wherein associated 
data is obtained from data input into tbe system and at 
least one second item type wherein associated data is 
10 obtained from an operation performed on the data 

associated with at least one item stored in a first 
database, inputting data into the system, searching tbe 
input data for first items, storing first items in the 
first database, reading the or one of the second items in 
15 a determining step including determining whether the first 
database includes the or each prereqcuisite item necessary 
to determine the one second item by obtaining associated 
data from an operation performed on data associated with 
at least one item stored in the first data base, storing 
20 the one second item in the first database if the or each 
prereq[uisite item is present, successively reading each 
other second item and storing it in the first database if 
the or each prerequisite item is present in the first 
database and outputting an indication that the system 
25 model can be produced if items of the model specification 
are stored into the first database. 

Preferably each second item is read successively. 
It is preferred that the method includes at least 
two items of the second type. 
30 It is preferred that items include parameters or 

variables such as Revenue or Outlay in a financial model* 

Associated data may include any type of data such 
as the name of items or quantities associated with the 
items. 

35 According to one embodiment an* item may include a 

group of parameters and their associated names. 

It is preferred that the method incorporates an 
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iterative process of reading second items whenever a 
second item is stored in the first database- 

The first database should be understood as 
including any memory storage area with or without 
5 divisions into separate areas or separate databases. 

Preferably the method includes storing first 
items in modules within the first database. 

Preferably each module is configured to perform 
operations on data associated with first items having at 
10 least one similar characteristic which are stored in the 

same module. 

It is preferred that the method includes a 
sorting procedure as items and associated data are stored 
in the first .database. 
25 It is preferred that the system produces an 

output indication if predetermined items are stored in the 

first database. 

It is preferred that the method includes nesting 

modules within other modules. 
20 Preferably the method includes the step of 

determining whether a second item type can be stored in 
the first database by associating the second item with an 
item determinant which specifies the or each prere<iuisite 
item for evaluation of the second item. 
25 Preferably the method includes a determinant step 

of searching the first database for the or each 
prerequisite item of the second item type. 

The determining step is preferably interpreted in 
a broad sense to mean any operation, evaluation or process 
30 of arriving at an outcome. 

The determinant and/or determining step may 
include a Boolean operation which produces a true or false 
result depending upon whether the or each prere<iui.site 
item is located in the first database. 

The first database may include one or more 
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separate storage areas. 

Preferably the result is true if prerequisite 
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items are located in the first database. 

The first items may correspond to input items. 
The second items preferably have corresponding 

item determinants. 

Preferably the second items are non-input items. 
The method may include the step of adding a 
second item to the first database if the associated item 
determinant evaluates to true. 

The method may include the step of providing a 
consolidated storage area for storing items and for 
evaluating item determineuats . 

Preferably the method includes the step of 
evaluating the item determinant for each second item not 
stored in the first database. 

The method may include the step of storing in the 
first database each second item for which the item 
determinant is true. 

The method preferably includes the step of 
storing second items in a second database if their 
associated prerequisite items are not located in the first 
database * 

Preferably the method includes repeating the 
evaluating step for any second item in the second 
database . 

Preferably the method includes repeating the 
storage step for each second item stored in the second 
database . 

It is preferred that the evaluating and storing 
steps are repeated until the storage step results in no 
30 additional second items being added to the first database. 

Alternatively the method includes repeating the 
evaluating and storing steps until all evaluated item 
determinants are false. 

It is preferred that the second database 
35 comprises- a consolidated instance array. 

The method may include the step of adding second 
items for which the item instances evaluate to false to 
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tiiG second database . 

It is preferred that any second item added to the 
first database after the evaluating step is performed on 
the second database results in the removal of that second 
item from the second database. 

It is preferred that the evaluation step is 
repeated on second items in the second database if the 
second item is transferred to the first database. 

The method may include the step of storing 
formula for second items in a formula database. 

The method may include evaluating each first 
and/or second item stored in the first database in 
accordance with the associated formula stored in the 

formula database. 

The method preferably relates to a spreadsheet 

model • 

The method may include allocating rows or columns 
for each item in the first database. 

•ia»e method may include the step of writing into 
the cells of the rows and columns the necessary formula 
from the formula database. 

It is preferred that the method includes the step 
of writing into the cells of the rows and columns any 
other information including formatting requirements of the 
cells . 

Alternatively the method includes the step of 
identifying first items re<iuired for each second item. 

preferably the method includes associating with 
each second item all first items reqpiired before the 
second item can be evaluated. 

The method may include storing second items and 

associated first items. 

preferably the method includes searching the 
first database for each second item for an occurrence for 
each associated first item and storing the second item in 
the first dateJsase. 

According to another aspect of the present 
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invention there is provided a computer program for 
inplesmenting the method for processing data for a system 
model in accordance with any one of the preferred 
' features . 

5 According to another aspect of the present 

invention there is provided a storage medium for storing a 
computer program described above. 

The words "comprising, having, including" should 
be interpreted in an inclusive sense, meaning that 
10 additional features may also be added. 

A preferred embodiment of the present invention 
will now be described by way of eacample only with 
reference to the accon^anying drawings in which* 

Figure 1 shows a seh«Biatic representation of a 

15 model specification; 

Figure 2 shows a schematic representation of 

model ii^put data; and 

Figure 3 shows a flow diagram of a method of 
processing data in accordance with the preferred 
20 embodiment of the invention. 

in accordance with the preferred enibodiment a 
spreadsheet model is produced by combining model input 
data for a particular model with a model specification. 

The model builder uses the model specification to 
25 process the model input data to ultimately produce the 
spreadslieet: model. 

The process involves three main tasks s 
identifying the items which must be created for a 
particular spreadsheet model; 
30 allocating rows or columns for these items; and 

writing into the cells of those rows and columns 
the necessary formula or other information and formatting 
the cells. 

The following description of the preferred 
35 enibodiment incon>orates the use of specially defined 
terms. These terms include: 

item, item instance and item determinant. 



10 



15 



20 



- 9 - 

in a financial model a particular parameter is 
evaluated according to a given formula or relationship 
between given variables. Thus a calculation of cash flow 
would be dependent upon the difference between Revenue and 
expenses. The particular names given to the variables is 
not important but they mast be given some identifier and 
in this exa««>le they are each referred to as items having 

particular item names. 

AS shown in Table 1, items are not scalar 
quantities but rows which typically contain numbers or 
formulae and may have associated name and label. Thus 
table 1 shows a very basic spreadsheet model with the 
items Revenue, BKpenses and Cash Flow with different 
occurrences of the items appearing in columns C to H. 
Table Is A three "it«n" model 

In each case there is only one instance of the 
items revenue, eacpenses and cash flow. Additional 
instances of each item might be referenced by terms such 
as Revenue to. Expenses A, Cash Flow 2, Cash Flow A. Thus 
if the model included items Revenue 1 and Revenue 2, these 
would be considered different instances of the item 
revenue • 
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REVENUE 


Revenue 


100 


100 


150 


200 


200 


200 
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EXPENSES 




50 


SO 


50 


SO 


50 


50 
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CASHFLOW 


Net Casli 
Flow 


tsC2-C4 






aF2-F4 


«G2-G4 


SH2-H4 
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25 The Cash Flow is calculated by subtracting the 

• Expenses in each column of row 4 from the Revenue in the 
corresponding column of row 2. 

Another feature of the above example is that the 



items Revenue and Expenses would typically be input items 
and thus model input data wbicb would be input to a 
co««mter by data entry personnel. The Cash Plow item 
however is not input to the system but is calculated from 
the input items Revenue and Expenses. Thus Cash Flow xs 
evaluated based on two input items each having one 
instance • 

From the above an instance can be defined as one 
or more lines which contain values copied from model input 
data and/or spreadsheet reference to model input data 
values, spreadsheet formula, labels and formatting 

information • 

An instance as described above is a ^concrete 
entity in that it is defined in terms of actual lines on 
an actual spreadsheet- However, before a spreadsheet 
model can be created it is necessary to perform operations^ 
with putative instances to determine the actual instances 

that will be recjuired. 

The term «item instance" is introduced to refer 

to instances in the abstract. An item instance may be 

actual instances on an actual spreadsheet or it may be a 

putative instance on a putative spreadsheet. 

There are two possible ways of approaching the 

definition of »Item Instance". 

Firstly by working from the concrete to the abstract, 
starting with actual spreadsheets and from there 
defining -mstances" , then -Items" as a class of 
actual or putative "Instance", and finally «ltem 
instance" as an actual or putative instance of an 
Xtem* 

secondly working from the abstract to the concrete, 
defining an "Item" as a class of variables (each Item 
defined by an unambiguous identifier, such as «REV") 
which might exist in a Model built from a Model 
Specification. «n Item instance can then be defined 
as an instance of the Item class. 

With these definitions we may proceed to consider 
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the first of three main tasks: determining which Item 
instances should exist in a particular model built from a 
Model specification and a set of Model Input Data, 

In the simplest method of the invention an Item 
5 Instance can be brought into existence as follows s 

if the Model Input Data contains input data for 

the Item Instance; and/or 

if the Item Instance is generated -inteimally" by 
the method of the Invention. This process is described 
10 below. 

In the method of the Invention, each Item must be 
associated with ^Determination Information" which can be 
used to determine which Item Instances should exist. The 
Determination Information must comiprise at least one of 
15 (a) or (b) : 

a) either: 

(i) a designation that instances of the Item 
may be associated with Instance Data; or 

(ii) a Spreadsheet Modeling I.anguage convention 
20 that allows instances of the Item to be 

associated with Instance Data. A 
spreadsheet Modeling Language convention 
may allow for instances of an Item to be 
associated with Instance Data by default 
25 (i.e« instances of an Item may be 

associated with Instance Data unless 
expressly designated otherwise) - 
Items which may have instances associated 
with Instance Data are referred to as 
30 Input Items"; and/or 

^3^) a logical expression (an ^Itom 

Determinant") evaluated according to a set 
of rules such that it may be determined for 
which of all possible instances of the Item 
35 the expression is TRUE. 

Thus an Item Instance should exist if: 

the Item is an Input Item and the Item Instance 
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has instance Data included as part of Model 
input pat a; or 

the Item has an Item Determinant and the Item 
Determinant evaluates to TRUE for the Item 
Instance . 

TO maintain the generality of the Invention, it 
is proposed that the rules for evaluating Item 
Determinants should not form part of the method of the 
invention but should be implementation dependent. The 
rules used in the computer program embodying the Invention 
are set out in the examples which follow. 

BKample 1: Model Specification with Input Item and Item 
Detenni nanfe 



Cosxa^BxiAs and 
Item Names 




Item Type Specifier 
and Qualifier 








REV 


Revenue 


I 








EXP 


Ebcpenses 


I 








CASHFLOW 


Net; cash flow 


NP<R£V I 1 EXP) 








DR&TB 


Discount xate 


I 








MPV 


Uet present 
value 


ND< CASHFLOW && DRATE) 



In this Model Specification: 

there are five Items: REV, EXP, CASHFLOW, DRATE 

and NPV; 

the Determination Information is as follows: 

Items REV, BXP and URATE are Input Items as 
designated by the Item Type «I" but they have no 
Item Determinant. Therefore Instances of these 
Items can exist if and only if Instance Data 
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have been provided for thexn; 

Item CASHFLOW is a non- input Item as designated 
by the Item Type "N" but it bas an Item 
Determinant « (REV || EXP)«. The Item 
Determinant is evaluated according to the rule 
that it is TRUE if a eorrespondinsr Instance of 
either RBV or EXP exists, and FALSE otherwise? 
and 

Item HFV is a non-input Item as designated by the 
Item Type "N" but it has an Item Determinant 
"(CASHFLOW DRATBO)". The Item Determinant is 
evaluated according to the rule that it is TROB 
if a corrBspondlnff Instance of CASHFLOW exists 
AND a GorroBpoodinff Instance of DRATB exists. 
Otherwise it is FALSE. 

Note that according to this flow of logic, an 
instance of NPV cannot exist unless there is a 
corresponding Instance of either REV or EXP. yet, the 
Item Determinant far WPV contains no direct reference to 

20 either REV ox BXP. 

The following is a sample of Model input Data 
which could be used with this Model Specification. 
Exanqple 2: Model Input Data 



15 



RBVl 


Steaming coal » 


7*50 


REV2 


Rental income = 


7*10 




BXPl 


Steaming coal = 


7*25 


EXP3 


Head Office = 4*10 3*0 




DRATE2 Discount rate 


= 10?6 



25 



When combined with the Model Specification, this 
Model input Data would cause the following spreadsheet 
Model to be" created. 



30 
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Exanple 3 : Resultcuat Spreadsheet; Model 



) 

2. 
3 


A 




C D 


REVI 
REV2 


_St^ining coul 
I^Renial income 


Pell PonlentK 


4 

« 5 
6 
7 


EXP) 1 Steaming coal 


Cell Contents i 


8 


CASHFLOW 1 


Steanning coal 


Cell Concents ; 


• 9 ^CASHFLOW! 


Renial income 


Cell Contents i 


: 10-CASHFLOW3 


Head Office 


Cell Contents 


II 








12 


DRATE2 


Discount rate 


Cell Contents 


Ts 






1 


14 


NPV2 


Net present value 


Cell Contents 


15 






1 

\ 



5 Xtiem Instances are determined as follows: 

Instances of REV, EXP and DRATE exist if tliey 
liave instance Data (REVI, REV2, KXPl, EXP3 and 
DR&T&2} ; 

Instances of CASHFLOW exist if there is either a 
10 corresponding Instance of REV (CASHFIiOWl and 

CASRFI»0W2} or a correspondin£r Instance of EXP 
(CASHFLOWl and CASHFIiOV^); and 
Instances of NPV exist if there is a 
corresponding Instance of CASHFIiOW and a 
15 corresponding Instance of DRATB <NPV2) • 

The preceding section describes which Item 
Instances should exist in a particular Model built from a 
particular set of Model Input Data* But it remains, to be 
shown how this is actually achieved in a computer program. 
20 Referring to Figure 1 a model specification 10 is 

esiiELblished having item names 11, item determinants and 
cell content information 13. A report array 14 contains 
formatting information IS for each type of report 16. 
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AS Shown in Figure 2 data which is input to the 
system is input as model input data 17 and is formatted 
with instance data including the name, instance ID and 

optional data. 

AS shown in Figure 3 a modeling system for 
implementing a particular spreadsheet model consists of 
model input data 20, an item instance database 21, a model 
specification 22 and a consolidated instance array 23. 

Processing of data occurs in accordance with the 
following four step procedure. 

Initially in step 1 as identified by item 24, the 
model input data 20 is scanned for instance data. In step 
2 the database 21 is created to register all the item 
instances (identified by item name and instance 
identifier) for which there is instance data. 

in step 3, once all the item instances identifed 
in model input data have been registered in the item 
instance database 21, each item in the model specification 
22 is read and the item determinant (if any) of each item 
i3 evaluated and the item instance database 21 has added 
to it all item instances for which the item determinant 
evaluates to true according to the rules of evaluation. 
This processing step is identified in block 25 of Figure 
3. 

The results of evaluating item determinants may • 
change due to the registration of additional item 
instances to the item instance database 21. Thns in a 
fourth step, step 4, it is necessary to repeat the 
evaluation step of step 3 to ascertain whether an item 
determinant would now evaluate to true for an item 
instance for which it previously evaluated to false. 

For each item in each repetition of the 
evaluation step of step 3, the consolidated array 23 is 
established to store instance identifiers of the instances 
to be tested against an item determinant. Instance 
identifiers may be drawn from an operation on the item 
instances registered in the database 21 (for example the 
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logical union of all instances of the item instances 
registered in the database) or from the application of a 
convention which identifies instances. The item 
determinant may be evaluated for each instance in the 
consolidated array 23. If it evaluates to true the item 
name and instance identifier are registered in the 

database 21. 

AS part of the process of reading each of the 

items in the model specification, step 3 which 

incorporates processing blocks 25 and 26 is repeated in 

step 4 until no more item instances are added to the item 

instance database. This is referenced in processing block 

item 27. Thus the addition of item instances to the item 

instance database 21 may change the evaluation of item 

determinants in step 3, but if step 3 results in no 

additional item instances being registered in the database 

21 then no matter how many additional repetitions occur of 

step 3 this will not change any item determinant from 

false to true. 

Applying these steps to Bjcample 3, it will be 
seen that Item Instances RBVl, REV2, EXPl, EXP3 and DFATE2 
are registered in the Item Instance Database in Step 2 
because they have instance Data. 

Instances of Item CASHFI.OW are determined in 
25 Steps 3 and 4. In the current embodiment this is as 
follows s 

all the Items referred to in the Item 
Determinant are identified. In Example 1, the 
Items REV and EXP are identified; 
30 - a consolidated Instance Array 23 is created 

containing the union of the Instance Identifiers 
of all the instances of the Items thus 
identified already registered in the Item 
Instance Database. In Example 1, this would 
contain the Instance identifiers -1" (derived 
from either REV and EXP) , "2" (derived from REV) 
and "S" (derived from EXP) . According to the 
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rules of evaluation it is impossible for the 
Item Determinant to evaluate to a?RUE for any 
other instance; 

the members of the Consolidated Instance Array 
5 23 are examined in orders 

the Item Determinant evaluates to TRUB for 
Instance identifier ~1" because the 
corresponding Item Instance of REV (i.e. REVl) 
is already recorded in the Item Instance 
Database. It is not necessary to consider the 
existence of EXPl; 

the Item Determinant evaluates to TRUE for 
instance identifier «2«' because the 
cowsponding Item Instance of BEV {i.e. RKV2) 
is already recorded in the Item Instance 
Database; and 

the Item Determinant evaluates to TRUE for 
Instance Identifier «3" because the 
corresponding item instance of EXP (i.e. EXP3> 
20 is alrea^ recorded in the Item Instance 

Database. 

The three Item Instances CASHFtOWl, CASHPIX>W2 and 
CASHFLOW 3 are therefore registered in the Item Instance 
Database; and 

25 in Step 4, this process is repeated, tthere are 

no more Item Instances of Item CASHFI^W added to the Item 
instance Database in this step. 

oaxe issue of whether the process can finish 
depends on whether instances of any item have been added 
30 in the most recent pass of step 3. 

It is possible for some instances of an item to 
be added in, say, the first pass of step 3, none added in 
the second pass, but more added in the third pass. 
However, if no instances of any item have been added then 
35 the model is complete. 

instances of Item OTV are also determined in 
Steps 3 and 4. in the current embodiment this is as 
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follows: 



all the Items referred to in the item 
Determinant are identified. In Example 1, the 
Items CASHFLOW and DRATE are identified; 
5 - a Consolidated Instance Array is created 

containing the union o£ the Instance Identifiers 
of all the instances of the Items thns 
identified already registered in the Item 
Instance Database* Assuming that NPV is 
10 processed before CASHFIiOW in the first pass of 

step 3, this would contain the Instance 
Identifiers ^^2" (derived from DRATH) . No 
Instances of CASHFLOW exist at this stage; 
the members of the Consolidated Instance Array 
15 are examined in order: 

the Item Determinant evaluates to FALSS for 
Instance Identifier "^2'' because the 
corresponding Item Instance of CASHFLOW 
{i.e* CASHFLOW2) is not registered in the 
20 Item Instance Dateibase at this stage. 

No Instances of NFV are registered in the Item 
Instance Database at this stage; 
- In Step 4, this process is repeated. By this 
time Item Instances CASHFLOWl, CASHFLOWa and 
25 CASHFLOWS have been registered; 

a Consolidated Instance Array is registered 
containing the union of the Instance Identifiers 
of all the instamces of the Items identified in 
the Determinant and already registered in the 
30 Item Instance Database. This would now contain 

the Instance Identifiers ^^l'' (derived from 
CASHFLOW), ^^2" (derived from either CASHFLOW or 
PRATE) and "^3" (derived from CASHFLOW) ; 
the members of the Consolidated Instance Array 
3 5 are examined in order: 

the Item Determinant evaluates to FALSE for 
Instance Identifier ^^1'' because the 
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corresponding Xt:em Instance of DXUlTE (i.e. 
DRATEl) is not registered in the Xtem 
Instance Z>atabase; 

the Item Determinant evaluates to TRUE for 
5 Instance Identifier ^^2" because the 

corresponding Xtem Instances of both 

CASHFLOW (i.e. CASHFI/OW2} and DRAT£ (i.e. 

BRATS2) are already registered in the Xtem 

Instance Database; and 
10 - the Xtem Determinant evaluates to FAI^SS for 

Instance Identifier ^^3^' because the 

corresponding Xtem Instance of DRATE (x.e. 

DRZVTE3) is not registered in the Xtem 

Instance Database; 
IS Only the Item Instance NPV2 is registered in the 

Item Instance Database; and 

- the process is repeated again. As -there are no 
more Item Instances added to the Item Instance 
Database in this step, the process can finish. 
20 It is possible in principle that an Item Instance could be 
added in Step 3 or on one of the repetitions of Step 3 and 
that in a later repetition of Step 3 the Item Determinant 
will evaluate to FAZ«SK for that Item Instance (perhaps 
because other Item Instances have been added) • A 
25 particularly problematic example of this is shown below. 
(The symbol "^l" stands for the logical operator «IIOT".> 
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Example 4: Cont;radict:ory Xtem Detexioinants 



Cozmaands and 
X^em Hames 


Isabel 


Xtem Type Specifier 
and Qualifier 








Item A 




ND(It6mC && lltexttB) 








Item B 




ND(XtemC && XtemA) 








Xtem C 




I 



Xn Example 4, if an instance o£ Xtem C bas been created 
5 from Xnstance Data tben the corresponding instance of Xtem 
A should exist if and only if the corresponding instance 
of Xtem B does not exist. But: the corresponding instance 
of Xtem B should exist if and only if the corresponding 
instance of Xtem A exists » This, is a logical 
10 contradiction which cannot be eliminated • 

The method of the Invention handles this by 
adding Xtem Xnstances to the Xtem Xnstance Database but 
not deleting them* It is therefore possible that the 
final version of a Model might contain some redundant Xtem 
15 Instances* With good model specification this should not 
happen and, if necessary, redundant Xnstances can be 
^^neutralised'' using cell content information. 
Allocating rows or columns 

Once the Xtem Xnstances necessary for a Model 
20 have been determined, it is possible to allocate rows or 
columns to the Instances. 

Xt is proposed that the method of allocating rows 
and columns be implementation dependent so as not to limit 
the generality of the Xnvention. Xn particular: 
25 it is not essential for all rows or columns to be 

on a single spreadsheet. The Spreadsheet 
Modeling Iianguage might contain methods of 
specifying that different Xtem Xnsteinces appear 
on different: sheets, or that a Non-defining 
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Occurrences of an Item Instance appear on 
different sheet from tbe Defining Occurrence; 
and 

it is not essential for a row or column to occuxxy 
5 the entire width or length of a spreadsheet. 

The term '^Spreadsheet Fragment" is used to 
describe a single rectangular portion of a 
spreadsheet which is of sufficient size to 
accommodate a particular Model. This allows 
10 several (possibly interacting) Models to be 

built on a single spreadsheet. This does not 
prevent a Spreadsheet Fragment from being an 
entire spreadsheet » but it need not be» 
Xn the exaxirples it is assximed that a Model 
15 Specification is read 8e<^entially. As each Xtem is 

encountered, a row or column is reserved for each Item 
Instance. Blank spaces or other formatting controls 
embedded in the Model Specification may be used to 
indicate empty lines, column headers, underlines, changes 
20 in ntunber formats, or page breaks* 

Xt is to be understood that, if any prior art 
publication is referred to herein, such reference does not 
constitute an admission that the publication forms a part 
of the common general knowledge in the art, in Australia 
25 or in Einy other country. 



lli\Sti»'lS\K«tf|>^ep«Cl\r»OI94 SI«C.<l9C 6^0l*/0i 
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Variations and modifications can be made in 
respect of the invention described above and defined in 
tbe following statement of claim: 

1. A metbod for processing data for a system 
model including the steps of providing a model 
specification having a plurality of types of items 
including at least one first item type wherein associated 
data is obtained from data input into the system and at 
least one second item type wherein associated data xs 
obtained from an operation performed on the data 
associated with at least one item stored in a first 
database, inputting data into the system, searching the 
input data for first items, storiiig fir.pt items in the 
first database, reading the or one of the second. items xn 
a determining step and determining whether the f xrst 
database includes the or each prere<,aisite item necessary 
to determine the one second item, obtain associated data 
from an operation performed on data associated with at ^ 
least one item stored in the first data base, storing the 
one second item in the first database if the or each 
prerecauisite item is present, successively reading each 
other second item and storing it in the first database xf 
the or each prerequisite item is present in the first 
database and outputting an indication that the system 
model can be produced if items of the model specif icatxon 
are stored into the first database. 



Figure 1: Model Specification 
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Model Specification 
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Figure 2: Model Input Data 



Instance Data (name, instancelD and optional data) 
Instance Data (name, instancelD and optional data) 



Instance Data (mnne, instancelD and oiUional data) 



Figure 3: Method of Determining Item Infitances 



Mudcl.lnpul Data 
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Slops t iind 2 
Scan Model liipul 
DqIii untt record 
Insinnccs ii) !IDB 



Rtfciml Input InManco 



Repeal Sicp 3 




I>eicnnuiaiii! 




CcmsoHclaifid 
Inistancc Array 
(a«aied for each tcein 
and destroyed after liein 
JOcieriiUnani has been 
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Use 
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Step 3: performed 
for each licm: 



Sicp 3a: 
read Item 
Dcicmiiimnt; 
reodllDB: 

build CIA. 



Step 3b: 
use Item 
Determinani and CIA 
to tdeniiry new 
Instances; 



Yes 



Item Instance Database 



Read 



Insianccj; 



ftem Name 
Item Name 
hetit Natne 
ttein Name 
hew Name 



InsiancelD 
tnstanceiO 
fminncelD 
ftisfaitcefO 
ftxsmiicetO 



(grows with Model) 
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Step 4: have any 
new Instances been 
added to IIDB? 



Add new Instances idenuGed m Step 3 
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Proceed to allocaie 
rows and write cell 
contents 



